A transformation stylesheet defines how to transform a source document into an output document. For instance, an eXtensible Stylesheet Language (XSL) stylesheet has a set of rules that determine how to transform a source eXtensible Markup Language (XML) document into an output document. The output document may also be an XML document, or may be another type of document, such as a Hypertext Markup Language (HTML) document, or a Portable Document Format (PDF) document. Typically, an XSL stylesheet defines the formatting style of the output document, such as text color, line spacing, etc. However, the XSL stylesheet may also define alterations that transform the structure of the source document into a different structure. For example, the structure of nodes in a source XML document may be transformed according to the XSL stylesheet to produce an output XML document with nodes arranged in a different order, or replaced with different nodes altogether. Similarly, the structure of a source XML document may be transformed according to the XSL stylesheet to produce an output HTML document that is structurally different and not just translated into HTML. Thus, a source document can not only be transformed into an output document according to formatting rules that are included in an XSL stylesheet, but more broadly, the XSL stylesheet can be used to transform the source document in many other aspects, beyond just formatting.
Unfortunately, the term “stylesheet” is somewhat inadequate to describe the capabilities of an XSL stylesheet, because an XSL stylesheet can clearly include rules for more than just formatting style. The term is further complicated by the fact that the acronym “XSL” is commonly used to refer to a group of related technologies, including XSL Transformations (XSLT), XPath, and XSL Formatting Objects. Details regarding the differences between these related technologies are not significant here; however, further information is available through the World Wide Web Consortium (W3C) website http://www.w3.org/Style/XSL/. Despite the apparent inadequacies of the terminology, the term “stylesheet” in the context of XSL is commonly understood in the art to include rules for all types of transformation, and it is intended that the broader aspect of the term shall apply herein, in accord with this common understanding.
Transformation rules provided in an XSL stylesheet are particularly useful, because an XSL stylesheet can be employed to transform various source documents containing different information into a single desired uniform output structure and format. An XSL stylesheet is also especially useful for transforming a large amount of source data into a structure and format desired for display in a Web browser program.
Because of the misleading terminology applied in naming it, an XSL stylesheet might be viewed as an XML equivalent to a Cascading StyleSheet (CSS). However, although a CSS is well suited for formatting, it is not well suited for defining structural transformations. Thus, a CSS is not equivalent to an XSL stylesheet. To better understand the differences, it is instructive to review how a CSS is used, and review the relationship between the CSS and the output document. An entire CSS is often embedded as a section of a source HTML document. Alternatively, CSS elements may be integrated into a source HTML document in an “in-line” manner. In any case, formatting is accomplished as defined by the CSS while the source HTML document is being rendered by the Web browser. Such integration makes it relatively easy to update a CSS while modifying a source HTML document in a text or graphical editor. However, this integration makes it difficult to apply the same CSS to multiple source documents to achieve a desired consistent result. A CSS can also be a separate document that is linked to a source HTML document. However, it is difficult to ensure that the CSS still provides a desired formatting when changes are made to the source HTML document, especially when structural changes are made to the source HTML document. Since XSL stylesheets can define structural transformations in addition to formatting, it is easier to modify only an XSL stylesheet so that the source document is transformed into an output document that is rendered as desired.
Because, an XSL stylesheet defines a transformation, a one-way mapping exists between an XSL stylesheet and an output document produced by it. Some current systems utilize this mapping in a graphical user interface (GUI) to ease development of XSL stylesheets. For example, a product called STYLUS STUDIO™ by Excelon Corporation includes a visual stylesheet editing mode. XSL stylesheets can be built using a drag and drop interface that supports JAVA™ extension functions for data conversion. The interface provides a graphical mapping between a text window showing a tree structure of the XSL stylesheet code and another text window showing a tree structure of the output document code. This mapping may be useful for sophisticated users familiar with XSL code, but also tends to limit the benefits of XSL stylesheets to such users. It is thus desirable to provide an interface that does not require an understanding of code, so that a wider range of users can benefit from XSL stylesheets for generating output documents in a desired structure and format. Specifically, it would be desirable to provide an interface that enables an unsophisticated user to readily develop an XSL stylesheet.
Another product called XML SPY XSLT DESIGNER™ by Altova GmbH provides a GUI that presents an XSL stylesheet in a graphical form, in a main design window. From a data source window, a user can drag and drop XML data elements into the main design window. The main design window presents the XML data element and enables the user to add presentation tags, such as tables, hyperlinks, and graphics. A resulting stylesheet is automatically generated from the graphical representation in the main design window. The user can then apply the stylesheet to a data source (displayed as a tree in the data source window), enabling the user to preview an output document with a built-in browser. Thus, XML SPY XSLT DESIGNER enables a user to graphically create an XSL stylesheet and preview an output document. However, such a system still requires a relatively sophisticated user that understands XSL stylesheets enough to work on an XSL stylesheet itself, even though the XSL stylesheet is in graphical form. Moreover, the preview capability is limited to the one-way mapping of the XSL stylesheet, which is no different than a standard browser that renders the output document according to the XSL stylesheet. It would be desirable to empower a broader range of users by providing a GUI that enables unsophisticated users to simply indicate a desired output form and structure and propagate the desired output back into an XSL stylesheet without having to understand how the XSL stylesheet transforms a source document to achieve the desired output in a document.
Because an XSL stylesheet is directly related to a rendered output document, it would further be desirable to enable a two-way mapping, so that a user can make changes to a rendered output document and propagate those changes back into an XSL stylesheet. Transforming a source document according to an XSL stylesheet is a one-way operation that requires the source document to be an XML document. Thus, a two-way mapping would require maintaining the mapping as changes are made to the output document. Such reverse propagation would empower a broad range of unsophisticated users to make structural and formatting changes to one output document through a GUI and propagate those changes back to the XSL stylesheet so that the XSL stylesheet could be applied to transforming a number of source documents.
One attempt at such a GUI is an XSL stylesheet editor under development by International Business Machines Corp. (IBM). The IBM editor provides a “What You See Is What You Get” (WYSIWYG) user interface that displays an output document created by transforming sample XML data according to an XSL stylesheet. However, the IBM editor is not a true two-way system. A user can add objects to an output document, but the addition does not first affect the output document and then propagate back into the XSL stylesheet. Instead, the IBM editor simply determines where the objects should be added in the XSL stylesheet, and directly modifies the XSL stylesheet. For example, if the user wishes to insert text at a given place, the user needs to select a stylesheet template, choose a position in the XML tree below the template, and choose a menu command, such as insert text. The IBM editor uses the output document as a reference, but does not actually propagate changes in the output document back to the XSL stylesheet. The result is an unnatural usage for users who are not familiar with the structure of XSL stylesheets. It is preferable to enable the user to choose a point in the output of the transform and type. This simple process is very natural and intuitive to a broad range of users, because it is the same process used for word processing, which is very familiar to a majority of users. The prior art cannot provide this simple approach, because there is no reverse-propagation mechanism, which would enable a user to provide input directly to a preview window and determine precisely where the input should go in the transformation stylesheet. In short, the prior art does not enable a user to modify an output document through a WYSIWYG editor, and have the modification propagate back to the transformation stylesheet.